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Abstract 

Current Internet of Things (loT) development requires service distri¬ 
bution over Wireless Sensor and Actor Networks (WSAN) to deal with 
the drastic increasing of network management complexity. Because of the 
specihc constraints of WSAN, centralized approaches are strongly lim¬ 
ited. Mnlti-hop commnnication used by WSAN introduces transmission 
latency, packet errors, renter congestion and seenrity issnes. As it uses lo¬ 
cal services, a decentralized service model avoid long path communications 
between nodes and applications. But the main issue is then to have such 
local services installed on the desired nodes. Environment Monitoring and 
Management Agent (EMMA) system proposes a set of software to deploy 
and to execute such services over WSAN through middleware based on 
Contiki OS. This contribution presents EMMA middleware, methodology 
and tools used to determine efficient service mapping and its deployment. 

Keywords: Internet of Things (loT), Wireless Sensor Network (WSN), 
Service Choreography (SC), Middleware, Mobile Agent and Petri Network 

1 Introduction 

The development of the Internet of Things (loT) has some emphasis about 
current scientist issues and future industrial applications. Among the loT ap¬ 
plications, the Responsive Environments (RE) are a part of a novel technological 
area. RE aims to transform our daily environments into intelligent spaces. His¬ 
torically the domotic systems were automata systems for controlling appliances. 
Nowadays the term of RE is referring to an environment connected to Inter¬ 
net. On one hand, the data collection is used by remote service providers to 
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manage macro issues, i.e. the energy providers which have to regulate energy 
production. And on the other hand, the different appliances are managed by 
different service companies over Internet. An alarm system can be monitored by 
distant security guardians and an health care system helps older people in their 
daily tasks. A major challenge for the loT is the sharing of a common network 
infrastructure between all current and future services. Wireless Sensor and Ac¬ 
tor Networks (WSAN) are used to connect locally the different appliances into 
a common wireless mesh networks. Appliances get an Internet access through 
others appliances. WSAN has important constraints in terms of bandwidth, 
throughput and payload. The network protocols proposed for WSAN, such as 
ZigBee, were incompatible with Internet Protocol (IP), the Internet standard. 

Since the 90’s, a lot of research works have experimented approaches around 
IP to facilitate WSAN incorporation into Internet. IPv 6 LoW Power Wireless 
Area Networks ( 6 L 0 WPAN) protocol has been standardized to use IPV 6 over 
IEEE 802.15.4 (ZigBee) developed for energy constrained devices [71[TU|TS]. An 
HTTP based application layer called Constrained Application Protocol (CoAP) 
is currently investigated to provide WEB based communication transactions 
mi- This protocol provides mechanisms for webservice interfaces like REpre- 
sentational State Transfer (REST) or Simple Object Access Protocol (SOAP) 
m- A lot of open discussions remain regarding software architectures for RE. 
Assuming that all appliances use a common network protocol, their applications 
stay heterogeneous which is addressed commonly by a central system. However 
in such situation, packet congestion appears around the routers according to 
network depth. Hence a new approach called Service Choreography (SC) is 
emerging to distribute locally the data exchanges. But the data heterogeneity 
is not still managed in framework found in literature. 

This paper focuses on methodology of design, analysis and deployment of 
such distributed services over Wireless Sensor and Actor Networks (WSAN). 
Section presents a literature review regarding the different programming ap¬ 
proaches of middleware to focus on current limitations of future required Re¬ 
source Oriented Architecture (ROA). The proposed framework Environment 
Monitoring and Management Agent (EMMA) is introduced in Section]^ This 
framework facilitates service choreography by providing a flexible distributed 
Publish-Subscribe mechanisms over CoAP. Efficient methodology to distribute 
such data exchanges is presented in Section according to node hosting capac¬ 
ity with the consideration of deployment processes. Section presents results 
about association mapping of this rules and discuss about efficient deployment 
process. Einally, Sectionconcludes about EMMA approach and future works. 


2 Related work 

A middleware is a piece of abstraction software which provides advanced func¬ 
tionalities of hardware and network engines to applications. It is composed at 
least of a network stack, a multi-task manager and the drivers. Hadim et al. 
m and Rahman et al. [22] detail the different challenges regarding the net- 
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work (scalability, mobility and dynamic topology), design (hardware abstrac¬ 
tion, resource awareness and modular programming) and data (aggregation, 
heterogeneity and quality of service). The design of middleware stays an in¬ 
tensive research domain because its technologies issues are inherent of large 
applications area. Rubio et al. |23j proposes a classification of programming 
middleware for WSAN: the macro-programming and the node-centric. 

The macro-programming consider a WSAN like an integrated system. Each 
node is a processing unit which executes particular operations assigned at a 
macro-level. The literature provides three main different approaches of macro¬ 
programming in which the system is considered indifferently like a cluster of pro¬ 
cessing units, a distributed database or a Multi Agent System (MAS). Kushwaha 
et al. m presents the OASIS architecture to design applications composed of 
different tasks distributed over the WSAN. They exchange directly their data in 
order to build computation flows over the WSAN. These tasks and their inter¬ 
connections are designed offline and deployed remotely from supervisors. Hence 
the operations are executed directly inside the WSAN but they are managed 
remotely. Costa et al. [3] proposes an architecture which considers the WSAN 
like a distributed database. Instead of collecting all data into a database, the 
requests are directly transmitted by broadcasting over the WSAN. The nodes 
resolve locally the request in order to provide an aggregated response to the 
requester. Fok et al. nni and Hackmann et al. [T^ have developed another 
macro-programming approach based on mobile agents. Each node has a Virtual 
Machine (VM) in order to execute soft-coded applications. An application is 
composed of different role based agents which exchange data and perform oper¬ 
ations onto a virtual tupple space. In MAS, each agent tries to satisfy its goals 
under its constraints in order to reach a global stationary point. Hence new 
constraints or goals can be added on runtime by the addition of agents in the 
virtual tupple space. This strong uncoupling between the application and hard¬ 
ware levels facilitates dynamic and online reprogramming of the WSAN such as 
there is no global problem formulation. Moreover, Liu et al. [20] show that this 
approach is useful to load-balance energy consumption over the WSAN using 
mobile agent moving over the nodes according to the residual energy repartition. 

The node-centric design considers the nodes like autonomous devices con¬ 
nected to WSAN. In such approach, the application term is referring to the soft¬ 
ware embedded into the nodes. They collaborate with others nodes or Internet 
services like a traditional distributed system. Hence the middleware provides 
mechanisms for networked applications including service discovery, protocol in¬ 
terfaces and data heterogeneity management. Dunkels et al |5| has developed 
a complete micro-operating system able to execute such applications in parallel 
on a single node. These applications communicate with other local applications 
through an event-based messaging engine and remotely with others services 
with the uIP stack. They propose an advanced solution using standard proto¬ 
col 6 L 0 WPAN to deploy remotely the binary applications over the air like on 
traditional computer systems. However in WSAN, the nodes can not be con¬ 
figured manually and individually according to the large scale of the network. 
Delicato et al |5] , Souto et al [9| and Khedo et al. [15] propose mechanisms based 
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on Publish-Subscribe pattern to configure remotely the data exchanges between 
the applications. The applications subscribe to a class of data through their 
middleware in order to receive them when they are published on the network. 

Both approaches have different interests according to the WSAN purposes. 
For example in data collection, a distributed database is more interesting than a 
node-centric approach because the system is homogeneous and do not require to 
collect systematically all data on a central database. In case of loT applications, 
the devices and the services are produced and added by different manufacturers 
along the network lifetime. The lack of standard middleware forces the manu¬ 
facturers to use node-centric middleware in their products. In such situation, 
the inherent heterogeneity of the applications and the network communications 
should be managed by supervisors in order to maintain network consistency and 
to preserve its resources. Kuorilehto et al. [18] conclude their survey that Cur¬ 
rently, they implement technologies and algorithms for application distribution 
but lack an approach combining a distributing middleware layer to OS providing 
a single node control. Recently, Cherrier and al. [3121 has proposed a new 
framework based on choreography of services for WSAN. They combine both 
approaches proposing a distributed node-centric based middleware with a high 
level language to describe macro-applications. The nodes provide web-services 
to produce or consume data which can be used simultaneously by different ap¬ 
plications. Hence the authors propose a model of Finite State Machine (FSM) 
in order to guarantee the system consistency according to the different network 
exchanges between the node applications. The authors compare their work with 
centralized approaches based on the orchestration of services in which a gate¬ 
way collects all the data and controls remotely the system. They demonstrate 
analytically and empirically that choreography model has better performances 
in terms of reliability, energy efficiency and scalability than orchestration. How¬ 
ever the resource limitations in term of memory on node do not allows them 
to manage the heterogeneity of sequential protocols used at application layer 
such as SOAP. Hence, Guinard et al m proposes a ROA framework for ser¬ 
vice choreography. This REpresentational State Transfer (RESTFUL) model 
uses the Publish-Subscribe mechanisms at resource level. Hence, the proto¬ 
cols which require sequential exchanges are implemented like a FSM of several 
Publish-Subscribe instead of a part of the webservice. An application is resumed 
by a graph of resource interactions described like Publish-Subscribe configura¬ 
tions. When a resource is changing, its contain is transmitted to its dependent 
resources in order to form a cascading computation flow over the WSAN. In 
literature review, the establishment of choreography at resource level between 
node applications are operated manually from supervisor. 

In this paper, the following questions are addressed to propose a Resource 
Oriented Architecture (ROA) middleware with self-reconfiguration mechanisms 
for service choreography over WSAN: 

How to map automatically the resources over the WSAN ? 

How to guarantee the consistency of their interactions ? 

And how to deploy them in a large scale network ? 
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3 EMMA Framework 


EMMA is a middleware for service choreography over WSAN. Its Resource Ori¬ 
ented Architecture (ROA) encapsulates node services into containers in order 
to form a resource tupple space. Among the different services, a VM executes 
reactive agents which models an augmented Publish-Subscribe mechanism dis¬ 
tributed over the WSAN. These agents have the ability to transcode CoAP 
requests in order to manage locally the heterogeneity with other middlewares 
or remote services using CoAP. Such as these agents are themselves resources, 
they have the capacity to be self-deployed with self-rewriting abilities. 

A SC is a service choreography formed by a set of services connected by the 
agents. The resource tupple space provided by the middleware forms a complete 
abstraction between the service choreography and its execution supports on 
node. A remote supervisor is responsible to define the best mapping of resources 
to deploy SC in order to preserve nodes and network load. This mapping takes 
in consideration the deployment process which is itself a SC composed of agents. 

This Section presents the middleware architecture with the different basic 
EMMA services of agent executions, system interfaces and data storages. The 
proposed graphical framework based on an augmented Petri Network provides 
an easy solution to design complex SC with composition features. Its use allows 
mathematical background to be reused in order to analysis event diffusion of 
the SC in order to guarantee its consistency. Finally, the different strategies 
of resource deployment are presented with peer-to-peer deployment, composed 
deployment and self-deployment. 

3.1 Middleware 

3.1.1 Resource Abstraction 

EMMA middleware is based on REST architecture which publishes data through 
CoAP resources. These resources are managed by encapsulated services which 
can be a driver, a processing or a memory storage. These services are imple¬ 
mented through an internal POSIX file API which provides resource reading, 
editing, creation or deletion by external CoAP requests. By default, the mid¬ 
dleware provides three types of services illustrated in Figure [T^: 

• Agent service (A): An agent resource is a script evaluated to send CoAP 
requests to other resources. Such as an agent is a resource, it can be 
created, modified or deleted by another agent including itself. 

• System service (S): A system resource contains node information such 
as routing tables, sensor data, actuator state, energy consumption, etc. 
These resources are input and output interfaces of the system. 

• Local service (L): A local resource contains temporary data used and pro¬ 
duced by agents to manage system resources. 
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PUT coap://node;5683/Ulight 
Payload: L#light+ + 
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(a) Middleware architecture 
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(b) Service choreography example 


Figure 1: The middleware provides an abstraction between hard-coded service 
of the node and their reprogrammable choreography by EMMA agents. 


3.1.2 Agent Service 

The agent service is used to model the service choreography by defining dis¬ 
tributed configurations of Publish-Subscribe. An agent is a rule to transmit the 
contain of a resource to another one according to the conditional resource state 
of the node. If a sensor updates its value contained in a resource, the sensitive 
agents update other depending resources which forms a cascading computation 
flow over the WSAN such as illustrated in Figure |lb[ The resource tupple 
space abstracts the network communication which allows the agent to update 
indifferently a local or a remote resource on another node. The resources are 
accessible through an Unified Resource Identifier (URI) composed of the node 
IP, the EMMA listening port and its service name. 

An EMMA agent a is a JavaScript Object Notation (JSON) file stored on 
node n which contains a set X of resources. It is composed of three elements: 

• A boolean activation function PREa{Xn) 

Example: /L/threshold < /S/brightness 

• A set of resource targets y GY 

Example: PUT[aaaa::2]:5683/S/light 

• A set of payload preprocessing functions POST/l{Xn,y) 

Example: { ’value’:’/S/light P + ’}; 

When its boolean activation function PRE^iX^) is true, it sends CoAP requests 
to target resource y GY according to POSTy{Xn,y) such as resume in Eq Q. 

If PREaiX„) is true -.WyGY^y ^ POSTy{X^, y) (1) 

action 
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Such as illustrated in following agent examples, the PRE field specifies the 
firing condition to send a request to each resource target stored in TARGET 
field. A target is defined by a CoAP action and an URL The payload stored 
in POST field for each resource target is a template file which is processed to 
replace variables by their resource value. If the payload contains mathematical 
operations, they are performed before to send the request. This payload can 
contain unresolved variables which are replaced by the resource values of the 
target node. Such as agents are also resources, they can create or delete agents 
including themselves which offers them self-deployment ability. 

1 { 

2 "NAME": "AgentSensor", 

3 "PRE": "L#brighness<50 && S#time%10 == 0", 

4 "POST": [ 

5 value' R#light+1, 

6 "L#brighness" 

7 ] , 

8 "TARGET": [ 

9 "PUT[aaaa::2]:5683/L/light", 

10 "PUT[aaaa::1]:5683/database/light" 

11 ] 

12 } 

JSON Agent 1: This agent is hosted on a brightness sensor which orders to 
a light to increase its value before to transmit the measured brightness to a 
database each 10 seconds if the mesured brightness is lower than 50. 


1 { 
2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 } 


"NAME" : "DiscoverDeployer", 

"PRE": "S#rand%2==0", 

"POST": [ 

"A#DiscoverDeployer", 

{ 

"PRE": "S#rand%5==0", 

"POST":[ 

"{'resources':S#resources}" 

] , 

"TARGET": [ 

"PUT[aaaa::1]:5683/NetworkInfo" 


"TARGET": [ 

"POST[ff02: :2]:5683/A/DiscoverDeployer", 
"POST [0::1]:5683/A/DiscoverNotifier" 

] 


JSON Agent 2: The agent DiscoverDeployer is a self-deployer agent which 
is sent periodically and randomly to its neighbors and installs on them the 
DiscoverNotifier agent. This agent will send periodically and randomly the 
resource list of the node to the proxy aaaa::l. 
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3.1.3 Heterogeneity Management 

The CoAP is based on Hyper Text Transfer Protocol (HTTP) which do not 
define data formatting nor URI specifications. Hence, this lack do not allows 
different CoAP middlewares to communicate directly. Traditionally, this issue 
is managed by a proxy server which translates the requests. In this sense, CoAP 
has an internal static Publish-Subscribe mechanism which allows the proxy to 
collect data from all nodes in order to ensure translations. 

The EMMA middleware allows this translation to be operated directly by 
the agents. Because their requests are fully specified through the fields POST 
and TARGET, they can send natively any kind of payload with any URI. 
For example, if a remote middleware uses Extensible Markup Language (XML) 
formatting language, the POST field of the agent should contain the required 
XML template. Moreover the agent can generate requests to subscribe to CoAP 
Observer mechanism in order to collect the data of another middleware. The 
combination of these two types of agent allows an EMMA node to subscribe 
data to another middleware in order to generate CoAP requests for another one 
such as illustrated in Listening 

CoAP Node 1 EMMA Node CoAP Node 2 

I I I 

I I GET /temperature I 




(registration) 

1 

Observe: 0 | 




1 

Token: 0x4a | 




+- 

-> 1 




1 

2.05 Content | 



(notifications) 

1 

Observe: 12 | 




1 

Token: 0x4a | 




1 

Payload: 22,9 C | 




1 <— 

-+ 




+-+ 

1 

/A/Transcoder | 



(translation) 

1 1 

1 <+ 

PUT /L/t 1 

Payload:?value=L#t I 




+-+ 

/A/Sender | 



(transmission) 

1 1 

1 1 

PUT /heater | 

Payload:?value=22.9 C | 


<- 


-+ < + 

1 

JSON Agent 

3: An EMMA node 

contains 

an agent which subscribes to 

Observer mechanism of the node 2. 

When a data is pushed by this node on a 


temporary EMMA resource, a transcoder agent is fired to generate a CoAP 
request for another node. This example illustrates heterogeneity management 
by an EMMA node between a temperature sensor and an heater which cannot 
communicate directly without the mediation of a proxy. 

The management of data heterogeneity for service choreography is a crucial 
issue which has not be found in literature review such as it requires to centralize 
data on proxy. The proposed specihcation of agents provides this feature on each 
node executing EMMA middleware. 







3.2 Service Choreography 

Service Choreography (SC) is a set of node web services interconnected in order 
to exchange their data in peer-to-peer fashion. They are configured through the 
augmented Publish-Subscribe of EMMA to distribute the deployment processes, 
the control-command loops between sensors and actuators, the service discovery 
mechanisms and the management of data heterogeneity. The design of SC is 
a challenge regarding problem complexity of concurrent accesses on distributed 
resources during event diffusion over the WSAN. The proposed framework uses 
an augmented Petri Network to model them at an abstraction level and to 
analyse their logical properties. 

3.2.1 Petri Network Abstraction 

EMMA design model is an augmented Petri Network in which requests are 
modeled by tokens, agents by transitions and resources by places. A transition 
is hred if these two conditions are satisfied: (1) a token appears in any input 
places and (2) the agent boolean test returns true. This transition activation 
produces a token for each output places and changes target resource values by 
corresponding pre-processed payload. Agents are also resources then, each tran¬ 
sition is associated to a place. If this kind of place is deleted, the associated 
transition is destroyed, in the same way for creation or edition. Therefore, this 
Petri Network model is dynamic and can change during its execution. This 
model illustrated in Figure [fallows SC to be simulated independently of its ex¬ 
ecution supports. Its behavior is validated thanks to classical algorithms found 
in literature of Petri Network such as safety, liveness, reversibility, determinism, 
termination, output-correctness and input-dependence [T]. Moreover classical 
patterns can be reused directly such as Sequence, Parallel Split, Synchroniza¬ 
tion, Exclusive Choice, Simple Merge, Multi-choice, Structured Synchronizing 
Merge, Multi-Merge, Arbitrary Cycles, Multiple Instances 



Figure 2: This distributed application computes the differential value pl{t) = 
pO{t— I) — pO{t) through agent tl and t2. If reaching the value 50, the agent t2 
is fired and uninstalls application including itself. 
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3.2.2 Dynamic Deployment Process 

Deployment process consists to install resources, including agents, on nodes. 
There are several ways to generate deployment process according to distributed 
application complexity, network topology and already deployed applications: 

• Direct deployment sends directly agents to each node from supervisor. 
This approach is interesting for configuration adjustments but not efficient 
if there are a lot of resources to deploy in deep networks and moreover 
unavailable in case of hidden node problem [6] . 

• Composed deployment illustrated in Figure [3a1 uses agents to carry other 
agents. They are sent on a node in order to install locally the resources 
and also to launch other deployment agents in a particular region of the 
WSAN. These deployment agents produce deployment chains like a Ma- 
troska game. This ability allows deployment process to be distributed over 
the WSAN, however the overhead produced by these agents is important 
according to the number of contained deployment agents. 

• Self-deployment is a flooding approach in which a deployment agent is 
broadcast to all neighbors. It contains all resources to deploy over the 
WSAN for a SC. When it arrives on a node, it deploys resources required 
by this node according to its resource context. Then it moves to next ones 
such as illustrated in Figure |3b| This kind of agents have a very large 
size but they are interesting in deploying common SC like the Service 
Discovery mechanism. 


These deployment chains are themselves SC. They are designed and validated 
by EMMA Petri Network and deployed by one of the above deployment way. 
Therefore, the application deployment process has to be considered during the 
mapping process of distributed applications. 




(a) Example of a Matroska deployment agent 
AD arriving on a node to install resources be¬ 
fore to sent next deployment agent to the next 
target node. 


(b) Example of a self-deployment 
agent which duplicates itself to 
its neighbors before to install the 
agents and to delete itself. 


Figure 3: Available deployment approaches with EMMA framework. 
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3.3 Choreography Mapping Methodology 

Mapping process consists to associate for each required resources of a SC an 
empty resource space on a node in order to minimize network communication 
costs. This mapping process is composed of three specification stages: functional 
design, instantiation process and SC deployment. 

3.3.1 Functional Design 

The functional design uses previously presented Petri Network to model the SC. 
The different input-output resources produced by node services are connected 
through agent resources A (modelled by transitions) in addition of temporary 
resource L (corresponding to places). This specification stage introduces the 
concept of scope which manages structural dependencies such as illustrated 
in top of Figure For implementation reason, a transition resource a must 
be on the same node n that the resources of its input places required by 
its activation function PREa{Xn). Otherwise for a reason of efficiency, a SC 
designer would like to force several resources to be located on the same node 
because of the frequency of their exchanges. All resources inside a common 
scope are mapped on the same node, and several scopes can be mapped on the 
same node. Then, the scopes form mapping specifications to determine enabling 
hosting nodes. The distribution of the scopes over the WSAN is itself specified 
by scope links: 

• Scope dependencies: A scope which requires several identical scopes is 
connected by a link of multiplicity M. For example, an agent of data 
aggregation requires M values produced by sensor resources. Hence the 
scope containing the agent is linked to the scope which models the sensor 
resources by a multiplicity parameter equal to M. 

• Network topology constraints: The SC design is operated independently 
of the target network. However it is possible to constraint the resource 
mapping in respect of network constraints such as the maximal number of 
communication hops between two scopes. 

3.3.2 Instantiation Process 

The instantiation process generates the global SC graph according to a target 
WSAN. The list of required resources produced by node services is established in 
order to determine the scopes which can be mapped according to their multiplic¬ 
ity parameters and the network constraints. The mapping problem presented 
in Section evaluates the set of mapping permutations in order to minimize 
an objective function representing global network load. In addition of the SC 
graph, the mapper adds the SC of the deployment process to keep free resource 
for the composed agents responsible of the agent A and temporary L resource 
installations. 
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3.3.3 Choreography Deployment 

SC deployment process generates for each node an agent which contains all 
resources to deploy on it. These agents are included into one to another by 
back propagation along a deployment path which is by default the routing tree 
from supervisor. Their composition is limited by their size according to the 
memory capacity of the nodes along the deployment path. This procedure 
is reiterated until that the WSAN coverage is reached in order to send the 
generated deployment agents to the corresponding nodes from supervisor. 


Functional view 


Instantiated view 


Deployed view 



Figure 4: Overview of the three steps of mapping process: Functional Design, 
Instantiation Process and Choreography Deployment. 
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4 Theoretical Background 

Application mapping problem consists to determine an efficient distribution 
of resources on nodes to minimize communication loads. Based on functional 
constraints and network topology with node hosting capacities, instantiated 
graph is mapped over WSAN with its deployment process. 

4.1 Model Definitions 

4.1.1 Network 

A WSAN is composed of a set of nodes N = {m, n 2 ,...} modelled by a distance 
matrix D in which dni,n2 represents the cost metric between ni and n 2 - By 
default, the cost metric is determined by the routing algorithm according to the 
number of hops between two nodes. It can model any others parameters such 
as the bandwidth, the link quality or an aggregation of them. If and only if the 
communications are bi-directional, Vni,n 2 S N : dni,n2 = dn2,ni- Because of 
node memory limitation, the routing tables of nodes are partial, a node ni can 
be hidden to n 2 and so dna.ni = o®- 

4.1.2 Scopes 

The set of scopes S = {^i,..., S'™} represents the whole application to deploy 
on WSAN. A scope is composed of resources which have to be deployed on 
the same node. Several scopes can be mapped on a same node, as long as the 
node capacity is sufficient. Two scopes are called linked if one resource of the 
first scope interacts with one of the second. This communication is modeled by 
data exchange frequency / (integer) and a weight p (integer) which represents 
number of packets required to transmit payload. Cost of communications a 
between two resources is denoted Ca- 

Oa — fa ^ Pa (2) 

The set of all communications from scope Si to scope S 2 is denoted 
defined in Eq ([^, such as the sum of all resource communication costs between 
scopes Si and S 2 . If the communications between two scopes are not symmetric: 
Asi^s 2 ^ 4 s2,si; hence Cs^^s 2 ^S 2 ,si' 

Csi,s 2 “ ^ ' ^a — ^ ' fa X Pa (3) 

CI^-A.s-^,S2 

The multiplicity parameter M(s) S K+* defines how many times scope s 
needs to be deployed on the network according to its dependent scopes s' G 
S'. Even if the number of scopes is determined during instantiation step, the 
multiplicity parameter is used by the mapper to exclude unavailable solutions. 
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4.1.3 Resources 


A resource r„ is an empty space of memory on the node n associated to a unique 
access path defined by scope/type/name. Each resource has a type denoted t 
corresponding to its management service. There are two main categories of 
resources: 

• Choreography resources are a set of resources which have to be mapped 
and deployed on nodes for the SC. 

• External resources are a set of resources already present on the nodes 
because they are a part of another SC or permanent system resources. 

Vn € N, Rn defines the set of resources on node n. Rn admits a unique parti¬ 
tioning by resource types with at most t subsets. A free resource denoted C is 
an empty space to host resource on a node according to its type j. Free resource 

set of type j is denoted Rn which is included in set of all resources on node 
n. An external resource is denoted f among set of already deployed resources 
Rn and Rn the set of external resources of type j. 

Vn e Af, U Rn (4) 


4.2 Problem Formulation 

4.2.1 Knapsack Problems 

The formulation of SC mapping problem is composed of two variants of the 
Knapsack problem: 

• Multiple Knapsack Problem (MKP): Each node is considered like a Knap¬ 
sack in which resources should be deployed according to the node capacity. 

• Multiple Choice Knapsack Problem (MCKP): The nodes have a finite par¬ 
tition for each resource type. In addition of the constraint on hosting 
capacity, the number of elements by type is limited on each node. 

There are also associative constraints when several resources are grouped in a 
scope, all of this resources have to be mapped on the same node according to its 
free resources by type. But a same scope cannot be mapped several times on the 
same node according to its multiplicity parameters. Indeed, multi-mapping of 
those target resources on the same node produced an ambiguity which cannot 
be resolved automatically without explicit designer indications. Finally, the 
problem formulation is defined by: 

How to map scopes which requires different number and types of resources 
over a set of node partitions which do not have the same hosting capacities 
in terms of resource type and memory size in order to minimize the network 
communication load ? 
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4.2.2 Mappable Applications 
Definition 1. size() operator is defined as: 

• size(r) refers to the memory space used by a ressource r 

• size(R) refers to the memory space used by all ressources in R 

• size(n) refers to the memory available on a node n 

Definition 2. Vs G C N denotes the set of nodes on which the scope s is 

mappable. A scope s is mappable on a node n if and only if: 

• Node n has a free resource r 2 for each resource r'l of the same type. 

Vr'i e Rl, 3r2 G R\^ (5) 

• Node n contains a resource fV with the same name and type for each 
required external resource ri. 

yri e Rl, 3f2 G Rh such os FT = f 2 (6) 

• Node n has enough available memory to contain resources of scope s 

size(Rs) < size{n) — size{Rn) (7) 

Definition 3. yn G N, Sn Q S denoted the set of scopes mappable on n. 

Definition 4. An application is mappable if (but not only if) all of its scopes are 
mappable according to their multiplicities: Vs G S,3Ns such as > M{s). 

The previous definition is used to trivially determine that a problem may 
not be satisfiable. Indeed emma-design-tools preprocessor evaluates possibility 
to have solution before to solve Pseudo-Boolean Optimization problem. 

4.3 Pseudo-Boolean Optimization 

Pseudo Boolean Optimization (PBO) is a problem defined by a pseudo-boolean 
function to minimize (or maximize), respecting the constraints expressed by 
equations (or inequations). Here, PBO is used to find the best mapping of 
whole SC over WSAN to minimize communication costs between nodes. 

Vs G S,yn G Ns : Xq, a;g..., x?, ..., xf G X 

represent boolean value of the scope s mapping on node n. The set of mapping 
combinations is equal to the sum of mapping availability of a scope s over the 
set of nodes : 

= ( 8 ) 

ses 
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4.3.1 Cost Function 

The cost function z{X) evaluates the impact of the mappings X on the net¬ 
work communication load. The Pseudo Boolean Optimization (PBO) solver 
determines the best combinations of scopes and nodes among the set X of per¬ 
mutations in order to minimize the communication costs between the linked 
scopes. The communication cost Csj_s 2 from the scope si to S 2 is defined such 
as the number of exchanged packets times the frequency of their exchanges. 
In addition, the distance of communication path between the nodes n and n' 
which hosts the scopes is defined in dn^n' such as the number of router hops. 
Finally, the pseudo-boolean function to minimize is defined in Eq. § such as 
the multiplication of communication costs between the pair of scopes and the 
number of router hops between them. 

min ziX) 'll Cs,s'dn,n'x'^xl (9) 

sGS raGA^s s'GS 


4.3.2 Constraint Set 

The minimization of the function z{X) is constraint by the following set of equa¬ 
tions to define available mappings. 


The Eq. (|10|) constraint the solver to map each scope on different nodes 

( 10 ) 


according to its multiplicity parameter M{s). 

Vs G S' : 'll x^ = M{s) 


neNs 


The Eq. (11) forces the mapping of linked scopes to have a network route 
between their hosting nodes. The constraint is inversely defined such as if there 
is no route between hosting nodes of two linked scopes = oo, their com¬ 
munication cost is forced to null which is a forbidden value to exclude solutions. 


H H H =0 

sGS nGNs s'GSn'^N^, 
d / =oo 


( 11 ) 


The Eq. (12) dehnes that the number of resource of type i contained in 
a scope s to map on n must be lower or equal than available spaces for this 
resource type on the node. 


yneN,yieT: J1 \Rl\x’:<\Rl, 


( 12 ) 


seS„ 


The Eq. (13) limits the total memory usage by the mapped resources on a 

(13) 


node to its available hardware memory. 


y-n G N : ’'ll x^size(Rs) < size(n) — size(i?„) 

sGS„ 


16 






5 Procedure and Evaluations 


This section resumes the installation procedure of Service Choreography (SC) 
on a WSAN composed of EMMA and others CoAP nodes. The deployment 
process is evaluated for the two kinds of deployment agents proposed in EMMA 
framework. The experimental support of self-deployment and composed agents 
is a SC for Network and Service Discovery mechanism. The results explain the 
choice of composed agents for SC deployment in EMMA mapping engine. Then, 
the resolution time of mapping problem is investigated on a classical problem in 
distributed systems: the Philosopher Dining. This example offers an enough SC 
complexity in order to provide a representative benchmark. These evaluations 
are not compared with other solutions because authors were not able to find 
in literature review similar approaches for automatic mapping and distributed 
deployment of SC. 

5.1 Installation Procedure 

1. Network and Serviee Discovery consists to recuperate the lists of nodes 
and their resources in order to determine the map of the WSAN composed 
of the network topology and node services. 

(a) EMMA nodes are discovered by the Agent previously presented 
which self-deploys on each EMMA node an agent which pushes pe¬ 
riodically and randomly the list of contained resources of its hosting 
node to the supervisor. Because the neighbors and route tables are 
included in system resources, all 6 L 0 WPAN nodes are discovered. 

(b) Other CoAP nodes are directly requested from the supervisor on their 
Resource Discovery (coap://[IPv 6 ]/.well-known/core) to get the list 
of their resources including their meta description. 

2. Service Choreography (SC) Deployment maps and deploys the different 
SC according to the discovered services and network topology. 

(a) Common SC are self-deployment agents which are responsible to in¬ 
stall common SC such as log collection agent and energy management 
configuration presented in Section |3. 2. 2[ 

(b) Mapping Process determines the best mapping of SC in order to 
minimize the network communication load and built the composed 
deployment agents presented in Section]^ 

(c) SC Deployment launches the different deployment agents on their 
WSAN area. This deployment is terminated when the Discover Noti- 
fier agents previously deployed transmit the complete list of deployed 
resources for each node. 

3. CoAP Node Integration consists to build and launch manually the agents 
in order to connect them to deployed SC. The data heterogeneity at CoAP 
layer is managed by translator agents such as presented in SectionfS.l.SI 
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5.2 Network and Service Discovery Deployment 


EMMA agents allow deployment process to be performed by three different ap¬ 
proaches: direct deployment^ composed deployment and self-deployment. Direct 
deployment is the common approach in most of contributions for SC middleware. 
However, it produces an important load in deep network because all deployments 
are transmitted from the supervisor. Below results compares the two proposed 
strategies by EMMA between a self-deployment Agent in Eigure ^ and a 
composed Agent [l] in Figure [5a] alone a 14-hop network. The experimentation 
evaluates the best strategy to deploy the Service Discover mechanism. 


Deployment time analysis 



node number 


Deployment time analysis 



node number 


(a) Composed agent contains a Matroska (b) Self-deployment agents contains all 
of deployment agents to deploy SC. agents to deploy for all nodes. 


Figure 5: EMMA deployment process benchmarks. 

Above figures print deployment time D equal to agent writing time W to 
store agent contained in payload of size P, transmitted in T ms to node and 
executed in L ms on it. Such as agent execution is processed by block, trans¬ 
mission time of deployment agent i is equal to total transmission time minus 
writing time on next node which is resumed in Eq |14[ 

D(i) = W{i) P {T{i) - W{t + 1)) -b L{i) (14) 


Figure [5a] shows the impact of cumulated agent overhead along the deployment 
path. For each node, the deployment agent contains SC agents and the com¬ 
posed agents for the next node. This strategy is interesting in distributing 
the deployment process over WSAN areas which avoids network congestion on 
routers close of the supervisor. However the deployment of identical SC by this 
approach produces a useless redundancy. Figure 5b presents the deployment 
of a self-deployment agent which is broadcast over the WSAN. It deploys the 
SC on the node at its arriving before moving on the next nodes. Its constant 
overhead is low regarding contained SC, however its use for the deployment of 
whole SC implies that its payload is very large. Finally, the self-deployment 
is efficient for installation of common SC at initialization in order to avoid re¬ 
dundant compositions whereas the composed deployment is used for resource 
deployment delegation to a local node in the WSAN area of interest. 
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5.3 Philosopher Dining Mapping 

Service Choreography (SC) mapping process is evaluated on a classical com¬ 
puter system problem of concurrent algorithm for synchronization issues. This 
application models a set of appliances which have to share energy tokens in 
order to avoid simultaneous energy consumption. For example in Smart Home 
application, electric-cars should not reload their battery at the same time that 
the hot water tank. In EMMA functional design, each philosopher is a scope 
composed of two places which models the tokens and two transitions for their 
exchanges such as illustrated in Figure [6a] The Figure |6b| presents the mapping 
result for 20 philosophers on 4 nodes with its composed agent of deployment. 



(a) Functional view in simulator. 



(b) Mapping process results. 


Figure 6: Dining Philosopher SC 

In Figure the mapping solver is evaluated according to the number of 
philosopher scopes and nodes in the WSAN. The number of generated con¬ 
straints in Figure [^increases proportionally with the number of nodes whereas 
the number of scopes has a low impact. The Figure [Tbj shows an exponential 
rising of the resolution time according to the number of nodes which means that 
the size of the WSAN is the major factor instead of SC complexity. 



Figure 7: EMMA Application mapping benchmarks. 
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6 Conclusion 


This paper presents EMMA framework which provides a set of tools to design 
distributed architectures for Responsive Environments (RE). Its Resource Ori¬ 
ented Architecture (ROA) provides an abstraction layer between the WSAN 
and its networked applications. The different services provided by the nodes 
are interconnected by a distributed Publish-Subscribe mechanism in order to 
form a Service Choreography (SC). Instead of proposing a new model, this 
work is original through the adaptation of well-known mathematical models to 
design and validate SC. Moreover, the framework implementation is based on 
standard technologies in order to propose an automatic solution to map, deploy 
and execute SC over heterogeneous WSAN. Hence this framework should be a 
first step toward distributed loT applications with self-reconfiguration features. 


Annexe: Implementation 

The EMMA middleware is implemented on Contiki OS by a set of standalone 
module applications. It is composed of the Erbium CoAP server-client, a Pile 
System (FS) for resource management with a JSON parser and a preprocessing 
engine for variable parsing. These modules communicate by an event messaging 
engine in order to take advantage of micro-controllers sleeping mode for energy 
saving purposes. The different component footprints are provided in Table 


Modules 

RAM 

Program memory 

emma-client 

381 Bytes 

8267 Bytes 

emma-server 

456 Bytes 

4528 Bytes 

emma-resource 

648 Bytes 

4108 Bytes 

emma-JSONparser 

0 Bytes 

382 Bytes 

emma-preprocessor 

95 Bytes 

4116 Bytes 

emma-service-system 

60 Bytes 

2845 Bytes 

emma-service-numeric 

10 Bytes 

576 Bytes 

emma-service-agent 

210 Bytes 

6586 Bytes 

Total 

1.9 KBytes 

31.4 KBytes 


Table 1: Memory footprints of EMMA modules on Contiki OS. 

The EMMA mapper is a JAVA application with Human Computer Interface 
(HCI) to design Service Choreography (SC) and to print graphically their 
mapping on the WSAN. It is composed of a CoAP proxy based on Californium 
framework to collect network and service informations and a PBO solver based 
on SAT4J framework. The different results have been experimented on COOJA 
simulator using ATMEL avr-raven board composed of a radio transceiver IEEE 
802.15.4 and an ATmegal284PV micro-controller 8-bits running at 8 Mhz with 
16 KBytes RAM and 128 KBytes Flash memory. 
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